As computing power and ubiquity has been increasing, so too has people's reliance on computing, be it in the form of computer hardware, computer implemented services, or computer aided processes. As reliance on computing has increased, users of computing have come to apply computing to cover sensitive data and functions. Users routinely store private information, such as personal contact information, in their smart phones. Users rely on computerized functions, such as credit card transactions, without giving it a second thought. Indeed, the degree of integration is such that many users feel lost without their laptop, cell phone, or credit card, much as past users felt lost without their wallets or purses.
Unfortunately, this reliance on computing has created such a large store of sensitive data and functions that malicious third parties become attracted to, and attempt to access those data and functions. Some malicious third parties may simply seek to corrupt those data and functions. Others may come to steal. Accordingly, computer security systems have been developed to prevent unauthorized users from accessing sensitive data and functions.
Computer security systems are specific to a particular context. A context comprises the boundaries where a given security authentication mechanism is valid. Historically, the context has been that of a computer application. For example, a corporate user might have one password for their human resources application and another password for their accounting system. Thus, the context of the first password is that of the human resources application, and the context of the second password is that of the accounting system. Alternatively, the context may be that of a computer hardware platform such as a computing device or network. For example, logging onto a personal computer may provide access to personal applications on that computer that do not have application specific security. That personal computer may be authenticated by a network security service on a corporate local area network (LAN), such that networked drives, networked printers, and other networked computing assets may be made available to that authenticated personal computer.
However, the more sensitive the data or function, the more layers of security administrators add. Additional security has led to a proliferation of additional contexts and consequently a proliferation of authentication credentials corresponding to those additional contexts, all for a user to manage. For example, it is not unusual to require a password for network access, another password to access a corporate database on that same network, and an encryption key for an encrypted record on the corporate database, even though the same user is accessing that record from the that same LAN.
Presently, with the advent of the Internet hosted services, contexts associated with new application, and their specific credentials have also proliferated. Where once a user might need only to track their passwords for their personal home network, their work account, and their debit/credit card personal identification number (“PIN”), that user may now need to track individual accounts for different Internet services, each service representing a different security context. For example social networks (e.g. Facebook™), electronic mail services (e.g. Gmail™ or Hotmail™), and individual software services (e.g. Salesforce.com™) all have their own security contexts and therefore manage credentials separately.
Similarly, with the advent of mobile devices, new security contexts associated with computer hardware platform and their associated security credentials have proliferated. It is not unusual for a user to track passwords for work and personal computers, and lock codes for their cell phone and/or tablet device. In combination, the proliferation of software services and computer hardware platforms has resulted in a veritable explosion of security contexts.
This explosion of security contexts has created challenges for present day application developers. Users desire the implementation details of their computing resources to be abstracted away. Regardless if an application resides on a corporate network or is cloud based in the Internet, users desire a consistent user experience, and for disparate security mechanisms to be as integrated as possible, all without compromising security. For example, a user may wish to delegate authentication in an Internet application to their Facebook™ logon credentials. However, application developers are faced with the task with programming an authentication mechanism, integrating that mechanism with different contexts, and implementing on a wide variety of computing hardware and/or software platforms.
In sum, as software services and hardware platforms proliferate, application developers are spending increasing amounts of time on computer security at the expense of investing in developing compelling features for their applications. If the application developer does not create a compelling feature, users will not purchase the application. Yet, if the application is not secure, the users will still not purchase the application. Accordingly, there is a need, not addressed by the prior art, for an identity service to alleviate the aforementioned issues, and to provide computer security options not contemplated by the prior art.